KAFKA-20391: Improve types returned by the Connect REST API#22001
KAFKA-20391: Improve types returned by the Connect REST API#22001gomudayya wants to merge 1 commit intoapache:trunkfrom
Conversation
| @Path("/{connector}/topics") | ||
| @Operation(summary = "Get the list of topics actively used by the specified connector") | ||
| public Response getConnectorActiveTopics(final @PathParam("connector") String connector) { | ||
| public Map<String, ActiveTopicsInfo> getConnectorActiveTopics(final @PathParam("connector") String connector) { |
There was a problem hiding this comment.
To align with other endpoints, it is better to create an entity instead of Map
| Message msg = requestHandler.completeOrForwardRequest(cb, "/connectors/" + connector + "/offsets", "PATCH", headers, offsets, | ||
| return requestHandler.completeOrForwardRequest(cb, "/connectors/" + connector + "/offsets", "PATCH", headers, offsets, | ||
| new TypeReference<>() { }, new IdentityTranslator<>(), forward); | ||
| return Response.ok().entity(msg).build(); |
There was a problem hiding this comment.
With this return we are missing the status code now. Aren't these breaking changes and need a kip ?
| @Operation(summary = "List the current loggers that have their levels explicitly set and their log levels") | ||
| public Response listLoggers() { | ||
| return Response.ok(herder.allLoggerLevels()).build(); | ||
| public Map<String, LoggerLevel> listLoggers() { |
There was a problem hiding this comment.
Same here, could be better if an entity (similar to what we have in org/apache/kafka/connect/runtime/rest/entities) is returned instead of a Map
| @GET | ||
| @Operation(summary = "List the current loggers that have their levels explicitly set and their log levels") | ||
| public Response listLoggers() { | ||
| return Response.ok(herder.allLoggerLevels()).build(); |
There was a problem hiding this comment.
Is it ok to loose the 'ok' status code ?
muralibasani
left a comment
muralibasani
left a comment
There was a problem hiding this comment.
@gomudayya I have a few comments but main concern is by changing the return type, we are missing status code and is it ok for this ticket without kip? However to align with other resources, looks ok.
2 participants
Responsereturn types with specific types inLoggingResourceandConnectorsResourceto improve OpenAPI specgeneration
conditional status codes were left unchanged as they require
Responsefor status code control.